Providing users of computers with the ability to quickly find and display a piece of information, no matter what the information's format or location, is a challenge that the computer industry has struggled with for many years. Today this problem is more salient then ever as increasing numbers of individuals utilize computers in their daily routines and as the types of information stored on a computer continues to diversify.
Traditionally, as in Microsoft Corporation's WINDOWS® 98™, this stored information is kept within a data store on the computer in a hierarchical fashion organized with files of information or media stored within folders. While this method of data storage has been widely used for many years, it is limited in that some data resides outside of the file hierarchy and users are constrained to format and locational limitations when searching for desired pieces of information. Accordingly, providers of computer software are currently working on data storage alternatives to the traditional file hierarchy.
An example of such a data storage alternative is disclosed in the commonly owned, co-pending application “SYSTEM AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION”, U.S. patent application Ser No. 10/647,058. This co-pending application was filed on Aug. 21, 2003 and discloses a data store that unifies storage into a single database. This database is the one place where all the data is stored; there is only one way to represent data to the database and only one way to query for data. By replacing antiquated file systems with this modern database technology, the data store will be easily searchable, more reliable, more accessible, and more resilient.
Once this unified data store is in place, there becomes a need to provide users with the appropriate tools and capabilities to interact with the stored data. Conventional operating systems, such as Microsoft Corporation's WINDOWS® 2000™, include a shell utility that provides a user interface for viewing various information about the computer. The shell typically includes a file system browser which enables users to navigate through the file system and locate and open files and folders. For example, Microsoft Corporation's WINDOWS® EXPLORER™ is a file system browser utility included with WINDOWS® 2000™.
The shell also enables users to view non-file items such as printers or fonts. This navigation is possible because a typical shell is programmed with the specific functionality to display these special items as if they were located in the file system. For example, in WINDOWS® 2000™, a user may open a “Printers” folder located within the Settings option on the Start Menu. Because printers are pieces of hardware and not files, this graphical representation of the printers is accomplished through utilization of custom code directed at displaying the printers as if they were files residing in the “Printers” folder. However, the use of custom code and custom drawing exceptions is complex for developers to implement, can be unreliable, and reduces the resiliency of the shell browser. Furthermore, if no custom code or custom drawing exceptions are in place for a type of data, the shell will be unable to display items of that type. Accordingly, conventional shells are limited in capabilities and in flexibility when displaying certain items to a user.
Another limitation of conventional shell browsers is a restricted ability to display items in a relational manner. Typically a shell browser is operable to display items only in the hierarchical fashion in which they are stored—organized within files stored within folders. For example, if a user desires to view all the picture files stored on a computer, that user must first place all such picture files in the same folder. Because the shell has limited capacity to determine relationships between items, it is difficult for a user to view files in a relationship driven context.
Furthermore, conventional shell browsers are limited in their ability to display sets of items within a contextually tailored environment that pairs pertinent information and tasks with the set of displayed items. Developers, by providing such pairings, can provide users with the appropriate information and tools needed to navigate among the items while facilitating the performance of commons tasks associated with the items. The prior art, however, does not allow developers to provide such experiences without the use of custom code.
An example of files presented in an enhanced environment through the utilization of custom code is the My Pictures folder which is included in Microsoft Corporation's WINDOWS® XP™ operating system. When image files are stored in the My Pictures folder, a user can view images at different sizes, rotate them, view a slide show, print images, or copy images to a CD. The shell in WINDOWS® XP™ has utilized custom code to incorporate these image-related tasks into this folder's display so that a user, when choosing to store pictures in this particular folder, will easily be able to navigate among the pictures and to perform common tasks with respect to the files. However, only files stored in the My Pictures folder are displayed in this environment, and custom code is utilized to create this functionality. While the My Pictures folder is an improvement over traditional presentation of items, developers still have limited ability to define such content-rich environments without utilizing custom code.
Accordingly, there is a need for an improved shell that is capable of displaying each item within a universal data store, and further, there is a need for an improved shell that is configured to present items within a universal data store in a relationship driven context. There is also a need for improved capabilities within the shell for developers to create custom environments that display items with appropriate contextual information and related tasks without needing custom code.